During initiation of a data or multimedia session by user equipment (UE) in a third generation telecommunication system, a PDP (Packet Data Protocol) context request is issued. As shown in FIG. 1, the PDP context request is generated in an SGSN upon receipt of a trigger from the UE. The PDP context request is sent to a Gateway GPRS Support Node (GGSN), which in turn communicates with a Policy Control Function (PCF) to ascertain what level of service and resources are authorised for that data or multimedia session. The PCF authorises (or rejects) setting up of the bearer(s) requested by the UB via the PDP context request.
If authorization of the PDP context is required (e.g. in 3GPP R5, if the PDP context request is IP Multimedia Subsystem (IMS) related), the PDP context request will usually include binding information such as an authorization token and flow identifiers. If the operator supports service based local policy (SBLP), the authorization of PDP contexts shall be performed.
During the creation or modification of a PDP context, the UE may define a traffic flow template (TFT). A TFT consists of one to eight packet filters, each identified by a unique packet filter identifier. However, as part of the SBLP authorization of the PDP context, the Policy Control Function (PCF) may send packet classifiers for flows carried by the PDP context. It is possible that the downlink packet classifiers defined by the PCF and the TFT set by the UE will have an overlap in the attributes they define.
One approach to dealing with this situation is for the GGSN to ignore either the TFT or the packet classifier. However, this approach may lead to dropping of packets or incorrect classification in the GGSN.